Customized Sales Software and Implementation

ABSTRACT

Customized sales software for consolidating, organizing and integrating data and process flow in a manner especially suited for sales operations. The customized sales software is customized to represent the user company&#39;s business process and integrates the user company&#39;s applications and data but does not change the user company&#39;s existing applications or databases. The sales software is designed in layers to enable seamless integration of legacy systems and external data sources, without requiring change to them, while at the same time enabling the introduction of new interfaces, transactions and processes. Integration with legacy systems and external data sources is possible at different layers within the software and may or may not utilize existing legacy system applications and processes. Generally speaking, integration with legacy systems and data sources may be either one or two way or in real time, depending on the requirements of a particular business process.

FIELD OF THE INVENTION

This invention relates generally to customized computer software and amethod for developing and implementing that software, and morespecifically to software for consolidating orders and sales.

BACKGROUND OF THE INVENTION

Currently most user companies run a plurality of processes, systems, andapplications. Current user company environments typically include thefollowing sales processes and functions: quoting and ordering, customerrelationship management, accounting, sales force automation, andforecasting. These various processes, through some allocation of dutiesand some cross-allocation of duties, take care of product pricing, usercompany masters, campaigns, payment history, shipping information,leads, and promotions.

BRIEF SUMMARY OF THE INVENTION

A sales application for consolidating, organizing, and integrating dataand process flow, the sales application including a plurality of tiersis provided. A user interface tier communicates with a customer, and atransaction engine tier performs a plurality of sales-related processes,whereby the transaction engine manages communications to and from theuser interface. A data repository tier stores sales-related data. Thesales-related processes require at least a portion of the sales-relateddata for completion. An integration engine enables integration of thesales application with a legacy system, which stores sales-relatedlegacy data of a third party. The sales-related processes furtherrequire at least a portion of the sales-related legacy data forcompletion. The sales application is integrated with the legacy systemby customizing the data repository in accordance with a configuration ofthe legacy system and by customizing the transaction engine to conformto business requirements of the third party.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates the relationship between a customer, sales software,and a user company in accordance with one embodiment of the presentinvention.

FIG. 2 illustrates the tiers of the sales software in accordance withone embodiment of the present invention.

FIG. 3 illustrates the tiered structure of the sales software and theintegration points with a legacy system in accordance with oneembodiment of the present invention.

FIG. 4 illustrates a flowchart of a scenario where the user interfaceand transaction engine tiers are driving the integration engine inaccordance with one embodiment of the present invention.

FIG. 5 illustrates a block diagram of a use of the data repository tierin accordance with one embodiment of the present invention.

FIG. 6 illustrates a flow chart of a sales operation of the software inaccordance with one embodiment of the present invention.

FIG. 7 illustrates a flow chart of an order operation of the software inaccordance with one embodiment of the present invention.

FIG. 8 illustrates a high-level flow of process and functionalitycomponents in accordance with one embodiment of the present invention.

FIG. 9 illustrates a customer component relating to a customer inaccordance with one embodiment of the present invention.

FIG. 10 illustrates a product component relating to product informationin accordance with one embodiment of the present invention.

FIG. 11 illustrates a price 1100 relating to pricing information for aproduct in accordance with one embodiment of the present invention.

FIG. 12 illustrates a quote component relating to quote information forpricing a product in accordance with one embodiment of the presentinvention.

FIG. 13 illustrates an order component relating to order information fora customer's product order in accordance with one embodiment of thepresent invention.

FIG. 14 illustrates a tiered architecture for the sales software inaccordance with one embodiment of the present invention.

FIG. 15 illustrates a subscription model for implementing the salessoftware in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Sales system and software of the present invention are provided forconsolidating, organizing, and integrating data and process flowrelating to sales processes and data. The sales system and software ofthe present invention are designed for rapid personalization andintegration with existing legacy systems and other external data. Theintegration of another party's legacy applications and legacy data maybe accomplished without modifying the party's existing applications ofdatabases.

Tiered Architecture

The sales system and software of the present invention is designed intiers to cater for the purposes and functions within it. These tiersenable the seamless integration of the sales system and software with aretailer's legacy systems and external data sources, without requiringchange to the legacy systems or external data sources, while at the sametime enabling the introduction of new interfaces, transactions andprocesses of the sales system and software.

The sales system and software enables seamless order placement by an endcustomer directly or via an employee at the user company or retailer. Asused herein, a “retailer” may be any traditional merchant that offersproducts or any other entity involved with a sales-related process, suchas value added resellers, distributors, original equipment manufactures,or other user companies that may benefit from the sales softwaredescribed herein. The end customer may be any individual or businessthat receives or provides a quote, places or receives an order, orotherwise has occasion to interact with the retailer. As seen in FIG. 1,the sales software 10 is loaded on a server 12. The customer 14 and acomputer 16 of the retailer or user company may access the salessoftware 10 from a personal computer. Two-way communication is enabledbetween the customer 14 computer 14 and the software 10 and between theuser company computer 16 and the software 10.

As seen in FIG. 2, the software 10 includes four tiers or layers: a userinterface 20, a transaction engine 22, a data repository 24, and anintegration engine 26.

The integration engine 26 enables the communication between salessoftware 10 and external data sources and systems. The integrationengine 26 uses a core library of components, described in more detailbelow, but includes the capability to connect to the external systemsthrough fully customizable connectors and connection types.

The data repository 24 includes a core structure for the data requiredwithin the sales system processes. Data repository 24 is fullycustomizable by incorporating a customer's or retailer's specificrequirements. Data in the repository 24 may be permanent or temporarydepending on its source and process requirements.

The transaction engine 22 manages the data repository 24, triggers theintegration engine 26 and controls the flow of information to and fromthe user interface 20. Using a core library of code to provide the flowof information to and from the user interface 20 as well as the mainbusiness processes within the sales system, the transaction engine 22 isfully customizable to each of a customer's or retailer's uniquerequirements.

The user interface 20 tier presents the software interfaces to acustomer 14 and enables the introduction and utilization of streamlined,efficient business processes. Using a core library of code in the basesales application, user interface 20 tier is also fully customizable toeach of a customer's or retailer's requirements.

The tiered architecture allows for integration of sales software 10 withlegacy systems and other external data sources at different tiers. FIG.3 illustrates the tiered structure of the sales software and theintegration points with a retailer's legacy system in accordance withone embodiment of the present invention. More specifically, FIG. 3 showspossible data flow between sales software 10 and a single legacy system.Retailers' legacy systems may be fully featured applications with alegacy system interface 28, legacy system transaction engines 30, andlegacy system database 32, as shown, or may be a simple database or datastore either internal or external to the business.

Integration of the sales software 10 with legacy systems and datasources may be either one or two way or in real time, depending on therequirements of a particular business process. In the embodiment shownin FIG. 3, two-way integration is provided between various of thelayers: between the user interface 20 and the transaction engine 22;between the transaction engine 22 and the integration engine 26; andbetween the data repository 24 and the integration engine 26.Integration to and from the legacy system layers occurs throughintegration engine 26. The integration engine 26 may send data to thelegacy system transaction engine 30 and the legacy system database 32.The integration engine 26 may receive data from the legacy systeminterface 28, the legacy system transaction engine 30, and the legacysystem database 32. The sales software and system of the presentinvention may communicate with external legacy systems and data sourcesusing any of various standard methods of communication. For example, asshown in FIG. 3, communication may be achieved via XML, MQ Series, HTTPget/send, NSF replication, file transfer, robots, API's, formatted text,email attachments, custom connectors or other suitable system. Inaddition, integration of the present invention is designed and built toallow for any other methods of communication to be employed.

Software 10 is operable with and customizable to multiple legacysystems, without practical limit on the number, either simultaneously orindividually at appropriate stages throughout an integration process. Asshown in the FIGS. 1 and 14, data taken from a legacy system may be feddirectly to the data repository or transaction engine and may thensubsequently be fed back to either a transaction process or database asappropriate. In deployment of the sales software and system, suchintegration is seamless to the customers as they typically interact onlyat the user interface 20 tier.

Sales software 10 draws data from retailer's legacy systems and otherexternal data sources and processes it into it's own data repositorywhere it may be added to with additional user entered data. Withreference to FIG. 14, examples of data held in legacy systems andexternal sources used in a typical telesales operation as fulfilled bythe software may include customer information, inventory information,discount or entitlement information, representative delegation levels,product pricing information, product detail information, productpromotion information, customer credit information, quote validationinformation, stock level information, or ordering and fulfillmentinformation.

On completion of a sales transaction processed by software 10, modifieddata is then transmitted back to the appropriate legacy systems and theoriginal data originally obtained from such systems is disposed of. Dataunique to the software 10 processes is maintained in data repository 24for re-use as required. Where required function or data storage does notexist in legacy systems, the sales software 10 may be customized toprovide such functions and data storage as described in more detailbelow.

During a transaction, while data is live in software 10, that data ischecked and verified at process points to ensure accuracy. Where theretailer continues to use its legacy systems for at least a portion ofthe processing or data storage, this verification ensures accuracyacross the two integrated systems. When the software 10 updates aretailer's legacy system or other external databases while the software10 is processing a transaction, the verification may occur eitherdirectly or through interim validation systems. Validation may occurs attwo points, (1) where data is brought into the application from a legacysystem, where the data is checked to determine correct formats,corruption, and validity based on defined rules defined in theapplication, and (2) where data is sent to other systems or processesbased on defined rules in the application.

Data Flow Across Tiers

FIG. 4 is a flowchart illustrating a typical scenario where userinterface 20 and transaction engine 22 drive integration engine 26.Integration engine 26 is capable of both foreground and backgroundprocess integration of data from legacy and external systems. The choiceof the type of integration conforms to the requirements within theretailer's process. Factors that may influence best deployment areperformance factors such as the size and complexity of the data beingintegrated during process integration. Where the performance of thelegacy system not consistent with the retailer's requirements, which iscommon when a legacy application is involved and data processing orsearching prior to any integration, background processing may beadvantageous. As seen in FIG. 4, the software maximizes the use ofbackground integration, even in processes that may depend on data from alegacy system.

A sales process is initiated at block 40. After initiation, it isdetermined whether data is required from a legacy system or otherexternal source, as shown at block 42. If no data is required from anexternal source, the main process is completed, as shown at block 44. Ifthe main sales process is completed without data retrieval completed,customer 14 may be notified that the data retrieval process is completedand the data is ready for use. If data is required from an externalsource, key data is either input or obtained from the process, as seenat block 46. Integration engine 26 is instructed to retrieve data. Thenext step, illustrated at block 48, is determining whether the mainprocess can continue without data. If the main process can continuewithout data, the user continues with the main process and dataretrieval is continued in a separate process, as shown at block 50. Itis then determined whether the main process can complete without data,as shown at block 52. If yes, the main process is completed, shown atblock 44. If no, as shown at block 54, it is determined whether the dataretrieval process is complete. If, at block 48, it is determined themain process cannot continue without data, the next step is whether thedata retrieval process is complete, shown at block 54. If the dataretrieval process is complete, the main process is complete, shown atblock 44. If the data retrieval process is not complete, the userprocess is halted while data is obtained, as shown at block 56. Afterthe data is obtained, the main process is completed, shown at block 44.

By way of example, the software 10 of the present invention is suitableto perform the process of building a quotation, the high level stepsincluding (1) obtain the accurate customer details; (2) obtain anystandard or special discounts that apply to the customer; (3) build alist of products to be quoted; (4) set any special terms or pricing; and(5) provide the resultant quote to the customer. In previous systems,these functions were performed in a linear fashion, even in a singlesystem environment, such that each step must be completed before thenext can be commenced. The transaction engine 22, user interface 20 anddata repository of software 10 avoid such time consuming limitations byallowing processes to continue, without requiring completion of anotherprocess, where possible. For instance, during a quote build wherecustomer 14 initiates an enquiry for all required customer data,transaction engine 22 may continue to build a list of products beforethe requested customer information is available. Once the customer datais available, customer 14 is notified and the relevant customer detailsand standard discounts set for the products is quoted.

As described in more detail, software 10 manages a variety of functions,and some of these functions require source information or data that isboth internal and external to the sales software and system. Examples ofsuch source information or data include customer information, productlists, default pricing, entitlement/discounts, product configurators,pre-installed inventory, discount delegation, promotions, clothing, orcustomer/product specifics. Data repository 24 is a relational databaseand is capable of maintaining all required data for the software tooperate as a stand alone application. However, retailers frequentlydesire to continue utilizing their legacy systems for performingspecific functions and may choose not to use the data repository 24 tohold all the required data.

For example, where a retailer selects the sales software and system ofthe present invention to improve efficiency of its sales operations butdoes not desire to change its current processes and systems used byaccounts and warehousing, data repository 24 may be used as a temporary,but not permanent, data storage area for the life of a transaction.Accordingly, on a first occasion of dealing with a customer, data may betransferred into data repository 24 at various but appropriate stageswithin a sales process. Then throughout the life of the sales process,this data is added to with customer input data that may not reside inany other system. When the sales process is complete, for example withsuccessful shipping of the goods and payment received, data known tohave been received from other existing systems is disposed of while thenew data, not previously held anywhere else is maintained. Historyrecords within data repository 24 are also populated to ensure that anaccurate historical record of the customer's sales transactions ismaintained. On subsequent dealings with the same customer, upon receiptof initial data from an external system, the new data and history isalso retrieved thereby increasing the efficiency of interacting with thecustomer.

FIG. 5 shows an example of possible interactions with data repository 24in accordance with one embodiment of the present invention. A salesprocess is initiated at block 60, requiring external data. Integrationengine 26 requests the required external data from a retailer's legacysystem or other external data sources. The data is then retrieved fromthe external data sources to integration engine 26 and then transferredto data repository 24 at block 62. The process continues at block 64until reaching a critical process point at block 66 where integrationengine 26 again requests external data from external data sources. Theexternal data is input into integration engine 26 where two-way dataflow occurs between integration engine 26 and data repository 24 andbetween data repository 24 and transaction engine 22, at which point, atblock 68, the data is validated. Data flows from transaction engine 22to data repository 24 and back from data repository 24 to transactionengine 22 when, at block 70, data changes are handled and communicated,such as notification, pricing changed, or quotes reissued. A master dataupdate is performed at block 72 when integration engine 26 requestsexternal data from external data sources. At block 74, the process iscomplete, when data is input from transaction engine 22 to datarepository 24.

There are several points in the sales software and system processesduring which legacy systems and external data sources may be contactedby integration engine 26. For instance, during a customer enquiry,required legacy data may include customer address data (includingdelivery or payment addresses), customer contact data, installedinventory data, or historical and ongoing customer sales data (includingdiscounts or past sales). During a quote build, required legacy data mayproduct data (including prices or descriptions from multiple systems),product validation (used for configured products), current stock levels,or representative delegation levels. During a quote send preparation,required data may include re-validation of key data already acquired,re-validation of products, or current stock levels. During a quote toorder conversion, required data may include re-validation of key dataalready acquired, re-validation of products, or current stock levels.During an order submission, required data may include re-validation ofkey data already acquired, re-validation of product, current stocklevels, or placement of order (to multiple systems). During an ordertrack, required data may include ERP system or external shipping agents.These operations are described in more detail herein.

Rapid Personalization

As described, the sales software and system of the present invention isoperational in its native form. However, it is also readily personalizedto support existing sales data and processes in a retailer's legacysystems. The rapid personalization process, which is implemented todevelop and integrate the sales software 10 of the present invention,includes three general stages: consulting, modeling, and implementing.These stages may be executed by a sales software and system provider andeffectively re-engineer the retailers' sales process. As used herein,“sales software and system provider” is any entity that may configure orotherwise cause software 10 to be operable with an external system.

In the consulting stage, the sales software and system providerinitially consults with a retailer to collect the necessaryconfiguration information about the retailer's existing sales systemsand to define the scope of the integration process. This may involvemeeting key process owners and users of the retailer's existing salessoftware. During the meetings, the current processes, systems, andapplications are explored to determine what should be incorporated inthe customized sales software. The dynamics between the process owners,systems, and applications are outlined to determine the manner in whichthe various components work together. Using this information, a plan ismapped for the implementation of the customized sales software. A baseset of initial requirements is defined using the base application as anexample The data and application owners are identified and informed ofthe objectives of the customized sales software, its development, andits implementation.

During the modeling stage, the sales software and system providerdevelops a prototype application. The sales software and systemprovider's existing sales software allows for rapid personalization tomeet the retailer's process requirements due to various featuresdescribed below. As shown in FIG. 14, the provider's existingapplication software includes a flexible transactional workflow engine,which drives sales software 10, with a breadth of preexisting features.Some of these features are shown in FIGS. 8-13 and are described in moredetail below. The sales software 10 is sufficiently robust withfunctionality that it may also be implemented in a purely native formwithout integrating with a retailer's current environment.

FIG. 14 illustrates how components, applications, databases and existingdata, and processes of the retailer's current environment legacy systemare mapped and integrated with the sales software 10 in accordance withone embodiment of the present invention. The transactional workflowengine interfaces with existing processes of the retailer's legacysystem, including the data and applications that drive them. Forexample, as shown in FIG. 1 and described in more detail below, aproduct pricing process may require data from a product pricing databasein the legacy system and reporting a result may require an accountingprocess of the legacy system.

As the various elements are mapped and integrated, sales-related processimprovements and control points are identified and recommended asenhancements that may yield productivity benefits and increased commandover key business controls for the retailer. For example, a customer maypreviously implemented a manual team to verify orders submitted to afulfillment process to ensure the order is priced properly; e.g., erroror fraud checking by representative or checking to determinesatisfaction all business controls defined by the customer. The salessoftware of the present invention can provide all the necessary checkingand verification functionality, thereby increasing productivity. Theresultant system represents a prototype integrated application, which isused in subsequent implementation as described in more detail below. Theinitial set of requirements are incorporated into the prototype and anew workflow and interface is customized and organized. Scenarios arerun in the prototype that are specific to the retailer's business asoutlined during the consulting stage. Training session may also be heldfor users and project managers, and requirements and changes critical tothe working prototype are identified and documented. Changes identifiedare implemented into the customized sales software, which results in atested version of the customized sales software.

Because the preexisting sales software is personalized and theretailer's existing legacy system is integrated therewith as shown inFIG. 14, the implemented system may include a substantial portion of theprototype developed in the modeling stage. For instance, the prototypemay constitute 60-80% of the ultimately implemented application.

In the implementing stage the provider implements and delivers theoperable sales software and system. The system reflects the retailer'scritical process steps and the functions necessary to execute them asidentified in the consulting stage. For reasons that will becomeapparent through the remaining description, the system results inimproved productivity of the retailer's processes and increased controlof the sales process flow. The subscription model shown in FIG. 15further ensures such productivity and control is maintained asmodifications may be continually implemented to the system that benefitthe retailer.

As shown in FIG. 15, the sales software and system provider may deliverthis solution in a subscription model, such that the provider and theretailer agree to a scope of the solution, for which the provider thenperforms and provides updates and enhancements to the application for apredetermined period of time. The updates and enhancements may include avariety of services, including process flow adjustments, new fields,other improved productivity features, and connection to other legacydatabases, as part of a subscription fee without additional cost,provided that the enhancements are within the scope of the solution.

One of the aspects of the sales software 10 that allows for rapidpersonalization is its preexisting robust architecture andfunctionality. A high-level flow of process and functionality componentsin accordance with one embodiment of the present invention, shown inFIG. 8, where each of the components may include a variety ofpreexisting features and functionality that allow for rapid integrationwith the retailer's existing system; the features and functionality arecustomizable in accordance with modeling stage. These preexistingfeatures and functionality are shown in FIGS. 9-13 and are now describedin more detail. These components may reside on the transaction engine oranother logical location within the sales system.

As shown in FIG. 9, a customer component 900 relating to a customer maycontain various information relating to the customer, which is usablethroughout the sales process. The customer component, also called a“super” customer record, is created during the integration stage byimporting data into the sales application system from existing dataavailable in a retailer's legacy databases or applications. If noexisting legacy customer data is available, a record will be created inthe sales software 10 as needed. Because these features andfunctionality are preexisting in the sales software 10, the system mayoperate with or without data from legacy systems.

The information contained in the customer component 900 shown in FIG. 9may include the exemplary native records with corresponding data orfeatures as listed in Table 1.

Customer Component

TABLE 1 Contact Information Name Address (Business & Personal) PersonalInformation (Spouse, Hobbies, etc.) Created manually or automaticallythrough the quote process Customer Profile Information IndustrySub-industry Size, revenue, etc. Customer Account Numbers Multipleaccount numbers may exist when process handles broad products setsCustomer Installed Inventory Customer Address Invoice addressInformation Ship to address Enterprise/corporate address CustomerPurchase History

The information in the customer component 90 is delivered as necessarythrough a variety of means to the transaction engine to support thesales process as the information is required. The delivery may beautomatic; for example, where then information is required to support anorder or fulfillment process, it is automatically imported to an orderform as the order form is transferred to the order or fulfillmentprocess. The delivery may also be performed through active alerts; forexample, when changes are made to a master customer address information.The delivery may also be performed manually by a user interacting withpull down menus on user interface 20; for example, a customer 14 mayinteract with a menu item, causing the item to drop down and display alist of contacts associated with a particular customer component, andthe user may then select the desired contact.

As shown in FIG. 10, a product component 1000 may contain variousinformation relating to a product available for purchase by a user,which is usable throughout the sales process. The system provides across industry-solution, capable of supporting sales environments for avariety of businesses and handling multiple product types. For example,the products supported may include products delivered through catalogs.The products may also include products requiring configuration,including those that are configured inside the sales software and system10 and products that are configured in a remote application for which aconfiguration file is uploaded to the integration engine 26. Someproducts may be put together or built in a variety of ways, in literallythousands of permutations, all of which are not valid. Configurationsoftware may be used to configure these products based on a set of rulesthat define correct building of the products. These configurations or“pre-defined configurations, may be delivered to the sales software viaa formatted file, such as an .xml file, or through other means. Thesupported products may further include products that are manuallyentered into the product component 1000, which may be used to handleexceptions, such as when an expected product cannot be located.

A product a product name, a part number or feature, a list price,product details or specifications, product images or pictures, productpromotions, product availability, and product catalog views all may bedefined in product component 1000 of the sales and system software.Product catalog views may be created by combining data from the multiplesources in order to provide the user with a complete view of a productbased on the how the product has been defined.

The information contained in the product component 1000 shown in FIG. 10may include the exemplary native records with corresponding data orfeatures as listed in Table 2.

Product Component

TABLE 2 Catalog Views Product Name Part Number/Feature Code List PriceProduct Details/Specifications Product Images/Pictures Basic CatalogSearch Capability Advanced Catalog Search by product category,sub-category, price Search Capability Promotions Integrated in Catalogviews Tools to define Promotions Automated/semi-automated discountapplication - rules driven, if applicable Upload capability Uploadsexternal configurations Customization is required to map legacyconfigurations to provider system Product Catalog Tools Individualmanual entry of products into a catalog Product catalog managementUpload of external files/databases Side by Side Product Comparesuser-selected products Comparison Email/download Makes product detailand prices available to user product information Upsell/down-sell/Recommendations cross-sell Automated application of products to quotesTools to create and manage. Product Availability

As shown in FIG. 11, a price component 1100 may contain variousinformation relating product pricing, which is usable throughout thesales process. The price component includes a pricing rules engine thatcontains customizable pricing rules. The pricing rules engine may eitherimport data and processes from the legacy system or use the preexistingtools and data structures native to the sales software and system Theinformation contained in the price component 1100 shown in FIG. 11 mayinclude the exemplary native records with corresponding data or featuresas listed in Table 3.

Price Component

TABLE 3 Discounting Mechanism Percentage Amount Set Price By Line itemBy Group Bottom Line Total Special Bid Support Delegation AuthorityAlerts To Sale Representative Checking To Management AuthorizationProcess Hard Stops Quote can not be sent/printed if delegation isexceeded Discounting over authorization not permitted. DelegationManagement Tools Set Delegation (two tier) Rules Based e.g., determiningapplication of Entitlement/Contract entitlements when product is onApplication of Discounts promotion Rules Based Promotion e.g.,determining whether Application of Discounts promotions are furtherdiscountable Pricing “scratch-pad” options Based on User Manual SaveAutomatic Save Customer Credit “worthiness” indicator Multiple pricingscenarios e.g., user can build multiple, Different Products quotablescenarios Different Prices e.g., scenario indicators Quoted PricingApproved Pricing Not Approved Single pricing scenario supportClothing/Up-sell Functionality for setting item as a up-sell or clothingoption Automatic alert of options e.g., maintenance alert

These tools and data structures are implemented in operation tocalculate the product price set for a customer. For example, the pricecomponent may determine the amount of discount a sales representativemay give, which processes exists to approve pricing outside a salesrepresentative's delegated authority, which promotions are available andhow are discounts associated with those promotions are applied, whethera customer has a contract entitling him or her to a discount on allproducts or specific products, how the contract or entitled pricingoperates when promotions exist on the same products, and what level ofdiscounting is available, e.g., line item, group, bottom line, andspecial bids.

As shown in FIG. 12, a quote component 1200 may contain variousinformation relating to developing a product quote to send to acustomer. As a quote is developed for a customer, the quote component1200 receives the necessary data from the price component 1100. Quotecomponent 1200 may also receive support rules, including a rule torequire specific conditions to be met before a quote may be sent, suchas pricing approval. The specific operation of quote component 1200 maybe designed during the model stage based on the retailer's requirementsas assessed during the consult stage. This may include designing a quoteformat that is sent to the customer as a standard quote with a fixedformat or a flexible format. The quote may also accord with thecustomer's requirements in cases where the customer expects the quote toappear in a certain format or file type. The sales and software systemof the present invention includes a template creation tool that allows auser to design a quote format and populate the quote output fields asrequired by the retailer's customers. The provider system also includesquote preparation tools to that performs an integrity check of a quote.

The information contained in the quote component 1200 shown in FIG. 12may include the exemplary native records with corresponding data orfeatures as listed in Table 4.

Quote Component

TABLE 4 Standard Quote Format Limited Flexibility in format Removablecolumns format Automated addition of terms and conditions Editablecomment area supports addition of images/pictures supports addition ofURL links Automated inclusion of brochure attachments automatedinclusion of URL links Email Print FAX PDF Format HTML Format includesorder button on quote, allowing customer initiate an order from thequote Customized Quotes Template Creation Tool WYSIWYG Tool PDF FormatMS XL Format MS Word Format HTML Format Email Print Fax Quote lockingbased If a user exceeds an amount of delegation discount he isauthorized to approve (delegation), then the software “locks” the quotefrom being sent to the customer until the proper authority approves thediscount. Automatic contact creation Link to opportunity Where a lead isprovided by an management —status opportunity management system tomanagement sales people, the link points to the OMS to provide a statusof the lead, e.g., in process, won, lost. Leads may include a name,contact information, or product interest etc. Edit quote ability Abilityto recall a quote that has been sent to a customer and edit the existinginformation and then re- quote with the same number, but a versionidentifier. Quote versioning

As shown in FIG. 13, an order component 1300 may contain informationrelating to the customer's order and order status. The sales softwareprovides a “single button” order capability, whereby a user may recall aquote and initiate an order process by selecting a single button. Thisfunctionality may provide significant productivity. Whereas typically asale representative sends a quote out then requests an order entry tooland re-keys the information in, the “single button” order allows thequote recall to be performed automatically. The order process is uniqueto a customer and may be highly personalized to meet the customerrequirements. Order component further 1300 supports functionality forchecking and verifying the order statuses, and this functionality may beextended to customers via the Web. The order component includes thenative capabilities shown in Table 5. The information contained in quotecomponent 1300 shown in FIG. 13 may include the exemplary native recordswith corresponding data or features as listed in Table 5.

Order Component

TABLE 5 XML output of Order File Order Status Performed by sales Checkrepresentative performed by customer via web

Operation

FIGS. 6 and 7 are flowcharts detailing sales and order process flow inaccordance with the sales software 10 of the present invention. Asdescribed, the sales software and system may be configured in an n-tierarchitecture including a client, or user interface tier, that isconnected to logic and data tiers across the Internet or other network.Accordingly, a client, or user interface tier, of the sales software belaunched on an Internet browser such as Internet Explorer, Netscape, orMozilla. By launching the sales software on a browser, local clientsoftware is not needed. A user logs onto the client tier using a uniquename and password such that application and user settings, permissions,and preferences are set. Because the sales software and systemfunctionality may be provided across a global network, the system maysupport multiple geographical regions, currencies, and languages.

FIG. 6 illustrates a flow chart of using a sales component of thesoftware. The sales component is typically run by an employee at theuser company for developing a price quote or developing an order for acustomer. The component is launched with a New Order/Sales Enquiry, asshown at block 80. The first step of the New Order/Sales Enquiry is toSelect customer. This step may be performed by entering a customer Name,either new or existing. If the customer Name is an existing customer,all possible matches are displayed in a pull down menu. The correctmatch is selected and details are completed automatically. If thecustomer Name is a new name, the employee is prompted for informationsuch as contact and business details.

After customer selection, a New Quote or Order may be created, as shownat block 82. The next step of the New Order/Sales Enquiry is to AddProducts, shown at block 84. This is accomplished by creating a newquote or order. Individual products are added, for example, via catalogselection, locating products by entering keywords or part numbers, orother suitable manner. The Product is added to a QuotePad. Defaultdiscounts, promotions, and clothing are implemented in the QuotePad. Thediscounts may be manually adjusted to modify seller and customerdiscounts based on permissions and delegation authority. Furtherproducts are added until the QuotePad is completed. Additionally, oralternately, specific product configurations may be uploaded. When thespecific product configuration is uploaded, product promotions andclothing are displayed. The configuration may then be added to theQuotePad, where, again, default discounts, promotions, and clothing areimplemented and may be manually adjusted. When the QuotePad is complete,it may be saved, shown at block 86, for future recall. Such saving maysave all product details on the QuotePad, enabling rapidquoting/ordering of “standard” or common products. Thus, the inventionalso provides for using a saved quote/order by recalling the savedQuotePad, shown at block 98.

The pricing for the order is finalized, shown at block 88, after allproducts have been added to the QuotePad. Finalizing the pricing may bedone by adjusting pricing/discounting on individual QuotePad lines. Thismay be done by applying a discount, applying a line price, or checkingitems against delegation levels. Alternately, pricing may be finalizedby adjusting pricing/discounting on all lines simultaneously. This maybe done by applying the same discount to all lines or setting a totalquote/order price, wherein pricing is calculated and set per line toattempt to stay within user delegation levels. As a step in finalizingthe pricing, discount approval is required if the pricing or discount isover the delegation level on any individual line. At that point, thequote/order is blocked until approval is granted.

After the pricing has been finalized, the quote/order is produced, shownat block 90. This may be performed from the QuotePad. The QuotePadincludes custom graphics based on the products quoted and includedcustom web links based on the products quoted. The quote may be furthercustomized by adding additional web links, setting up sections to bequoted, or adding custom notes/text. Once the quote details arefinalized, the quote is distributed, for example by print or email. TheQuote may be saved automatically for future reference.

To handle existing quotes and process an outstanding quote, shown atblock 92, the existing quote is retrieved using the customer's name, thequote number, or other suitable information. If appropriate, the quoteis amended by removing products, adding new products, and/or adjustingpricing and discounting. If amended, the quote is reissued and anincremental quote number may be assigned.

To process an order, shown at block 94, the order summary details arecompleted. This may be performed directly after producing and saving thequote/order, at block 90, or may be done after processing an outstandingquote, at block 92. This entails confirming or amending details such ascontacts (purchaser, shipping, billing) and addresses (shipping,billing), entering order specific data such as customer order number anddelivery instructions and, optionally, process payment via a credit cardor other payment mechanism. A confirmation receipt may be processed.Typically, a matching order number is assigned to the quote for easyreference.

To check the status of a current order, shown at block 96, the order maybe called up using the order number or other suitable information. Theinternal order status, shipping details, shipping tracking, invoicedstatus, and similar order details may then be checked.

FIG. 7 illustrates a flow chart of using an order component of the salessoftware, shown in FIG. 14. The order component is typically run by acustomer for placing an order and is designed for easy customer use. Forplacing a new order, a customer signs onto the system, shown at block100. If the customer is a registered customer, the customer does notneed to enter customer details as these are recognized from the sign on.If the customer is not a registered customer, the customer will have toenter customer details. To create an order, shown at block 102, thecustomer may add individual products, shown at block 104. This may beaccomplished via catalog selection, entering product keywords or partnumbers. The customer may compare products. In one embodiment, thecustomer may compare up to three products in side by side compare view.Product promotions and clothing are displayed for each product selected.If selected for purchase, the product is added to OrderPad. Defaultdiscounts, promotions, and clothing are displayed corresponding to theproduct. Further products may be added to the OrderPad until the orderis complete. During product selection, product configurations may beuploaded to the customer. At any point, the OrderPad may be saved forfuture recall, shown at block 106. Saving the OrderPad saves all productdetails on the OrderPad for future recall, enabling rapid ordering ofstandard or common parts. The saved OrderPad may be used by the customerat any future point. Thus, the invention also provides for using a savedorder by recalling the saved OrderPad, shown at block 112.

To process the order, shown at block 108, the order summary details arecompleted. This include confirming or amending details such as contacts(purchaser, shipping, billing) and addresses (shipping, billing). Orderspecific data is entered such as customer order number and deliveryinstructions, and the payment may be processed, for example, when usinga credit card. An order number is assigned. Current Order Status may bechecked, shown at block 110, by calling up the order using the ordernumber or other information. Shipping details, shipping tracking,invoiced status, and similar details may then be checked.

Using the sales component and the order component, at various stages inthe processes of adding products for quoting and/or ordering, varioussoftware processes are invoked; for example, customer default detailingand seller default discounting may be applied. Default discounts may bebased on standard discounting or uplift models, based on individualproducts or on product groups, specialized industry/product specificdiscount models, conditional discounts (for example, buy one of a firstproduct and one of a second product and receive 10% off of both), orother appropriate discounts. Applicable promotions may be identified andfull details made available to the user based on individual products orproduct patterns (for example, buy one of a first product and one of asecond product and this promotion applies). Product clothingopportunities may be identified and suitable products automaticallyadded. This may include individual products or product patterns (workingin conjunction with promotions).

Although the present invention is described with reference to specificproposed embodiments, persons skilled in the art will recognize thatchanges may be made in form and detail without departing from the spiritand scope of the present invention.

1. A sales application for consolidating, organizing, and integratingdata and process flow, the sales application comprising a plurality oftiers including: a user interface for communicating with a customer; atransaction engine for performing a plurality of sales-relatedprocesses, wherein the transaction engine manages communications to andfrom the user interface; a data repository for storing sales-relateddata, the sales-related processes requiring for completion at least aportion of the sales-related data; and an integration engine enablingintegration of the sales application with a legacy system for storingsales-related legacy data of a third party, the sales-related processesfurther requiring for completion at least a portion of the sales-relatedlegacy data, wherein enabling integration of the sales application withthe legacy system includes customizing the data repository in accordancewith a configuration of the legacy system and customizing thetransaction engine to conform to business requirements of the thirdparty.
 2. The sales application of claim 1, wherein the sales-relateddata includes customer data, product data, and price data, each requiredfor completion of the sales-related processes.
 3. The sales applicationof claim 1, wherein the sales-related legacy data includes customerdata, product data, and price data, each required for completion of thesales-related processes.
 4. The sales application of claim 1, whereinthe transaction engine includes predefined sales-related functionality,and wherein a determination to implement the predefined sales-relatedfunctionality for completing the sales-related processes is based onexisting capabilities of the legacy system.
 5. The sales application ofclaim 1, wherein customizing the transaction engine includes modifyingthe sales-related processes performed by the transaction engine based onthe business requirements of the third party.
 6. The sales applicationof claim 1, wherein customizing the data repository includes modifyingdata structures in the data repository in accordance with theconfiguration of the legacy system.
 7. The sales application of claim 1,wherein user interface is provided to the customer through a browserdelivered application.
 8. The sales application of claim 1, wherein thelegacy system includes a legacy system database.
 9. The salesapplication of claim 1, wherein the legacy system includes a legacysystem transaction engine and a legacy system database.
 10. The salesapplication of claim 9, wherein during operation the integration enginetransmits requests to the legacy system transaction engine and thelegacy system database.
 11. The sales application of claim 10, whereinduring operation the legacy system transaction engine and the legacysystem database transmit data responsive to the requests to theintegration layer.
 12. The sales application of claim 1, wherein thesales application supports the legacy system in accordance with asubscription agreement.
 13. The sales application of claim 12, whereinthe subscription agreement provides for adding enhancements to the salesapplication.
 14. The sales application of claim 1, wherein the legacysystem is external to the sales application.
 15. A method in a computersystem for facilitating electronic communication between a salesapplication and a legacy system of a third party, the method comprising:receiving through a user interface of the sales application a customerrequest from a customer; providing at least a portion of the customerrequest to a transaction engine of the sales application; accessing adata repository of the sales application, wherein the data repositorystores sales-related data, including retrieving from the data repositoryat least a portion of the sales-related data required for processing thecustomer request; determining whether the sales-related data issufficient to process the customer request; retrieving from a legacysystem that stores the third party's sales-related legacy data a portionof the sales-related legacy data required for processing the customerrequest, if the sales-related data from the data repository is notsufficient to process the customer request; and processing the customerrequest on the transaction engine, wherein the transaction engine iscustomized to conform to business requirements of the third party andthe data repository is customized in accordance with a configuration ofthe legacy system.
 16. The method of claim 15, further comprising thestep of updating the legacy system, if processing the customer requestmodifies the sales-related legacy data.
 17. The method of claim 15,wherein retrieving from the data repository at least a portion of thesales-related data includes retrieving customer data, product data, andprice data, each required for processing the customer request.
 18. Themethod of claim 15, wherein retrieving from the legacy system a portionof the sales-related legacy data includes retrieving customer data,product data, and price data, each required for processing the customerrequest.
 19. The method of claim 15: wherein the transaction engineincludes predefined sales-related functionality, and further comprisingthe step of determining whether to implement the predefinedsales-related functionality for processing the customer request based onexisting capabilities of the legacy system.
 20. The method of claim 15,wherein customizing the transaction engine includes modifying processesperformed by the transaction engine based on the business requirementsof the third party.
 21. The method of claim 15, wherein customizing thedata repository includes modifying data structures in the datarepository in accordance with the configuration of the legacy system.22. The method of claim 15, further comprising adding enhancements tothe sales application in accordance with a subscription agreement.
 23. Amethod for integrating data and process flow of a sales system with alegacy system of a third party, the method comprising: determining aconfiguration of the legacy system, including identifying legacy salesprocesses performed by the legacy system and legacy sales componentsstored on the legacy system; and mapping preexisting sales applicationsof the sales system for performing predefined sales-relatedfunctionality and preexisting sales databases of the sales system to thelegacy system based on the configuration of the legacy system, includingidentifying a subset of the legacy sales processes to replace withpreexisting sales applications and identifying a subset of the legacysales components to replace with preexisting sales databases.
 24. Themethod of claim 23 further comprising the step of customizing a datarepository of the sales system and a transaction engine of the salessystem to accommodate the configuration of the legacy system.
 25. Themethod of claim 23, wherein the step of mapping further includeslogically connecting sales-related data of the sales system to thelegacy system based on the configuration of the legacy system, whereinthe sales-related data of the sales system includes customer data,product data, and price data.
 26. The method of claim 23, wherein thestep of mapping further includes logically connecting the preexistingsales databases to sales-related legacy data stored on the legacy systembased on the configuration of the legacy system, wherein thesales-related legacy data includes customer data, product data, andprice data.
 27. The method of claim 23 further comprising the step ofcustomizing the predefined sales-related functionality based on theconfiguration of the legacy system.
 28. The method of claim 23 furthercomprising the step of customizing a data repository of the sales systemby modifying data structures therein based on the configuration of thelegacy system.